% This file is part of the i10 thesis template developed and used by the
% Media Computing Group at RWTH Aachen University.
% The current version of this template can be obtained at
% <http://www.media.informatik.rwth-aachen.de/karrer.html>.

\chapter{Implementation and Evaluation}
\label{evaluation}
\index{evaluation|(}

To demonstrate the concepts proposed in this thesis, I have implemented a prototype to simulate Role Administrations\ref{sec:roleadministration}.

\section{Database Design}

Database design in prototype type implementation is implemented in \citetalias{Derby} Database Management System (DBMS), and it is slightly different from previously mentioned in the Concept part\ref{sec:databasedesign}. Because lack of unique addresses in testing environment of the prototype, participants' unique addresses are simulated to a set of addresses consist of localhost addresses plus unique context names and the service name, e.g. For a company called MarketHuge, it has a unique address like: http://localhost:8080/MarketHuge, and the voting service provided by MarketHuge can be found in the address: http://localhost:8080/MarketHugeVote/vote. This type of address definition can identify same service name for different participants. In a traceability network, there is more than one participant provide services with the same name. Take the voting service as the example, If the other participant called MarketBig provide voting service too, the address of its service is: http://localhost:8080/MaketBigVote/vote, this address can be identified easily from other voting services. And this address definition also enables simulation of partial distributed environment in a single Application Server.  


%\emph{\textbf{company}(lid int not null primary key, comName varchar(50), address varchar(100))}\\
%Table \emph{company} stores all company's information in the traceability. For the security reason, RSS provides no interface to access this information, and authority to access this data should be provided very carefully.
%
%\emph{\textbf{roleGrant}(lid int not null, 	EPCClass char(18) not null,	roleName varchar(80),	expireDate date, primary key (lid,EPCClass))}\\
%Table \emph{roleGrant} stores General Role grant information about companies. If a company gets a General Role granted, a record about company's information, association EPC Class and expire date will be inserted into this table. By default, expire date will be set to one year after the date that the role is granted. In contrast, a record about company's information, association EPC Class and expire date will be deleted from this table when a company's General Role is revoked. 
%
%\emph{\textbf{itemTrack}(EPC char(27) not null, lid\_from int not null, lid\_to  int not null, ts timestamp,	primary key (EPC, lid\_from))}\\
%When an EPC event occurs in the traceability, the participant registers it to RSS server. With the help data conversion middleware, events can be converted into data records in this table. RSS uses this table's information to look for voting partners for the grant Role feature.\ref{sec:rolegrant}  
%
%\emph{\textbf{roleDictionary}(roleName varchar(80) not null primary key,	ts timestamp)}\\
%Table \emph{roleDictionary} stores all General Role's names. The role's name is the primary key of the table so that there is no duplicate General Roles defined in RSS.

\myFigure{ERerbacserver}
{Implemented data schemas in ERBAC servers}
{Implemented data schemas in ERBAC servers}

Figure \ref{image_ERerbacserver} describes data schemas in a participant's ERBAC server:

\emph{\textbf{DCPartner}(lid int not null primary key, comName varchar(50), address varchar(100))}\\
Table \emph{DCPartner} stores participant's directly connected partners' information. Access to this table's data should be authorized carefully. 

\emph{\textbf{sentTo}(EPC char(27) not null primary key, lid int, ts timestamp)}\\
Table \emph{sentTo} stores information about item transfer information. As the company sends out an item to the other company, this EPC event will be converted into a record in this table by proper event conversion middleware. A record in this table contains EPC of the item, destination company's id and time stamp of the event.


\emph{\textbf{receivedFrom}(EPC char(27) not null primary key,	lid int, ts timestamp)}\\
Table \emph{receivedFrom} stores information about item transfer information. As the company receives an item from the other company, this EPC event will be converted into a record in this table by proper event conversion middleware. A record in this table contains EPC of the item, source company's id and time stamp of the event.

\emph{\textbf{roleHierarchy}(roleName varchar(80) not null primary key,	position int)}\\
Table \emph{roleHierarchy} stores information about role's relationship for privilege inheritance. General Roles and Perspective Roles are structured as arbitrary tree. The position of a role is a 5 bits integer by default which means in the current schema only 5 layers are support in the role hierarchy. However, it is easy to extend the depth of role hierarchy by extend the position range. More details about the how role hierarchy works can be found in \ref{sec:rolehierarchy1} and \ref{sec:votealgorithm}.

\emph{\textbf{roleGrant}(lid int not null,	EPCClass char(18) not null,	roleName varchar(80),	expireDate date, primary key (lid,EPCClass))}\\
Table \emph{roleGrant} stores General Role and Perspective Role grant information for companies. If a company gets a granted, a record about company's information, association EPC Class and expire date will be inserted into this table. By default, expire date will be set to one year after the date that the role is granted. In contrast, a record about company's information, association EPC Class and expire date will be deleted from this table when a company's role is revoked. 

Data schemas in the RSS:

Although data schemas storing item flow information are simplified, data schemas for role administration are remained same as the Concept section\ref{sec:dataschemasinrss}, so the data schemas of RSS in implementation is the same as described in \ref{sec:dataschemasinrss}, readers can refer to \ref{image_ERrss} to look at data schemas.



\section{Role Administration Web Services}

For the scalability reasons, all the Role Administration modules are implemented in \citepalias{webservice}deploying on \citepalias{appsrv}. Here are implemented web services' interfaces classified by administration modules:

\begin{mylisting}
\begin{verbatim}

Grant Role:
boolean grantRole (String roleName, String EPCClass, String comId);
boolean vote (String roleName, String EPCClass, String comId, String serviceProvidedId);


Revoke Role:
boolean revokeRole(int comId, String roleName);

Add Role:
boolean addRole (String roleName);
boolean addRoleInHierarchy (String roleName);

Delete Role:
boolean deleteRole(int comId, String roleName);
boolean deleteRoleInHierarhy (int comId, String roleName);
boolean voteForDelete (int comId, String roleName);
\end{verbatim}
\end{mylisting}

Java documentation of interfaces can be found in source code package.

\section{Implementation Details}

\myFigure
{implRoleGrant}
{Simulated environment for role administration}
{Simulated environment for role administration}


\myFigure
{ParticalRoleHierarchyofMarketHuge}
{Role Hierarchy of MarketHuge}
{Role Hierarchy of MarketHuge}


Figure \ref{image_implRoleGrant} is a simulated environment for role administration in a traceability network. At the top is a RSS providing role services and tracking item transfers. There are four participants: Toptech, MarketHuge, MarketBig and MarketMuch. Company Toptech transferred three items to the other three companies and registered item transfer events in the RSS.

\subsection{Role Hierarchy}
\label{sec:rolehierarchy1}

Four companies in the Figure \ref{image_implRoleGrant} directly connected by item transfer relationships in the supply chain, they can define others Perspective Roles on their own decisions. As described in \ref{sec:rolehierarchy}, roles are structured in arbitrary trees. Figure \ref{image_ParticalRoleHierarchyofMarketHuge} is the role hierarchy maintained in MarketHuge's ERBAC server. It has seven roles defined and each role has a position integer to indicate its position in the hierarchy. Based on perspective information it has, MarketHuge assigned Toptech perspective role Directed Connected Manufacturer. In MarketHuge's ERBAC server, Table \emph{roleHierarchy} stores \textbf{roleName} and \textbf{position} pairs to set up the role hierarchy tree explained in Figure \ref{image_implRoleGrant}.


In Figure \ref{image_implRoleGrant}'s scenario, if Toptech is interested in having a General Role of Manufacturer with EPCClass 01.0000A89.00016F granted, it can invoke the web service \emph{grantRole} on the RSS. After checked records in the Table \emph{itemTrack}, RSS finds that there are three participants received items with the EPC included in the EPCClass 01.0000A89.00016F, it then invoke the \emph{vote} web services on MarketHuge, MarketBig and MarketMuch, waiting for their votes to make decision based on Simple Majority Voting.

\myFigure
{ParticalRoleHierarchyofMarketMuch}
{Role Hierarchy of MarketMuch}
{Role Hierarchy of MarketMuch}

\subsection{Vote Algorithm}
\label{sec:votealgorithm}

On the side of MarketHuge, a voter for the role grant, the decision to vote or not is based on simple policy: If the assigned Perspective Role (Directed Connected Manufacturer) for the applicant (Toptech) is at the upper position of the Target Role (Manufacturer) on the same branch of the role hierarchy tree, it will vote for role grant. In implementation, integers that indicate the positions of the Target Role and Perspective Role are used to compute the result that whether two roles are in the same branch of the tree. If the two integers have the same prefix which is the non-zero prefix of the Target Role, they are in the same branch. In the Figure \ref{image_ParticalRoleHierarchyofMarketHuge}, the non-zero prefix of Target Role Manufacturer is 11 and D.C.M has the same prefix, the MarketHuge will vote for granting Role Manufacturer with EPCClass 01.0000A89.00016F. In Figure \ref{image_ParticalRoleHierarchyofMarketMuch}, the Toptech is assigned with the Competitive Distributor. The prefix of Target Role Manufacturer is 11 but the prefix of the Perspective Role Competitive Distributor is 12. Therefore, MarketMuch will not vote for the Toptech. The source code of vote algorithm is listed below:

\begin{mylisting}
\begin{verbatim}
	/**
	 * Compare whether two roles are in the same branch of the role hierarchy.
	 * 
	 * @param posTargetRole			Position of target role in company's role hierarchy.
	 * @param posPerspectiveRole	Position of perspective role in company's role hierarchy.
	 * @return						true if target role and perspective role are in the same 
	 * 								branch of the role hierarchy.
	 */
	public boolean compareHierarchy(int posTargetRole, int posPerspectiveRole){
		//cast from int to String, which is easy to manipulate
		String posTargetRoleString = String.valueOf(posTargetRole);
		String posPerspectiveRoleString = String.valueOf(posPerspectiveRole);

		//set the prefix by the non-zero substring of target role. 
		//If two roles have the same prefix, that means they are in the same
		//branch in the role hierarchy.
		int idx = posTargetRoleString.indexOf("0");
		String prefixTargetRole = posTargetRoleString.substring(0, idx);
		String prefixPerspectiveRole = posPerspectiveRoleString.substring(0, idx);
		int result= prefixTargetRole.compareTo(prefixPerspectiveRole);

		if(result==0)
			return true;
		else
			return false;
		
	}
\end{verbatim}
\end{mylisting}



\section{Evaluation: Compare ERBAC with a current authorization concept}
\label{sec:compare}

As described in the \ref{sec:scadas}, SCADAS is a current authorization concept for distributed environment by using agents. It provides an alternative to deal with access control in traceability network. However, it still has problems in company address security. The agent travels in the distributed environment only hide the addresses from the requestor in the traceability, but it accepts data from target participants. If the participant gives its address to agent with malicious intension, address leaking remains. In addition, the agent could be a vulnerable target for attack. In ERBAC system, communication can be restricted into directed connected partner, which eliminate the possibility either a company exposes its address or a requestor gets address that should not be given. And low system alternation expense is another advantage of ERBAC system when comparing to systems have no relationship with RBAC system. Most enterprises have its own access control system on authorize employees' access to resources. As the RBAC's prevalence on access control area, enterprises can probably integrate ERBAC's concepts to exist access control system. This will not only save the system development expense, but also reduce the training expense of people working on the system.

%\begin{enumerate}
%	\item {Low system alternation expense. Most enterprises have its own access control system on authorize employees' access to resources. As the RBAC's prevalence on access control area, enterprises can probably integrate ERBAC's concepts to exist access control system. This will not only save the system development expense, but also reduce the training expense of people working on the system.}
%	\item {Agent's security problems. Distributed RABC can avoid the address leak threat when using Agents to control the access.}
%	\item {\todo {there could be more gaps}}
%\end{enumerate}  


%here

 \index{evaluation|)}